Add ExpressionAnalyzer for pluggable expression-level statistics estimation by asolimando · Pull Request #21122 · apache/datafusion

asolimando · 2026-03-23T18:03:49Z

Which issue does this PR close?

Part of #21120 (framework + projection/filter integration)

Rationale for this change

DataFusion currently loses expression-level statistics when computing plan metadata. Projected expressions that aren't bare columns or literals get unknown statistics, and filter selectivity falls back to a hardcoded 20% when interval analysis cannot handle the predicate (e.g. OR predicates, which are not expressible as a single interval). There is also no extension point for users to provide statistics for their own UDFs.

This PR introduces ExpressionAnalyzer, a pluggable chain-of-responsibility framework that addresses these gaps. It follows the same extensibility pattern used elsewhere in DataFusion (ExprPlanner, OptimizerRule, StatisticsRegistry).

What changes are included in this PR?

ExpressionAnalyzer trait and ExpressionAnalyzerRegistry (chain-of-responsibility, first Computed wins)
DefaultExpressionAnalyzer with Selinger-style estimation: equality/inequality via NDV, AND/OR via inclusion-exclusion, injective arithmetic (+/-), literals, NOT
ProjectionExprs and FilterExec use the registry for expression-level statistics
Three new default trait methods on ExecutionPlan (uses_expression_level_statistics, with_expression_analyzer_registry, expression_analyzer_registry) for injection, overridden by FilterExec, ProjectionExec, AggregateExec, HashJoinExec, and SortMergeJoinExec
The physical planner injects the registry after plan creation and re-injects after each optimizer rule that modifies the plan, ensuring optimizer-created nodes always carry it
AggregateStatisticsProvider and JoinStatisticsProvider (feat: Add pluggable StatisticsRegistry for operator-level statistics propagation #21483) consume the registry via the trait getter
Config option optimizer.use_expression_analyzer (default false), zero overhead when disabled

Are these changes tested?

21 unit tests for ExpressionAnalyzer
4 integration tests verifying registry injection survives optimizer rules
5 end-to-end SLT tests (OR selectivity, TopK, UNION ALL, hash join filter pushdown)
Existing projection and filter test suites pass unchanged

Are there any user-facing changes?

New public API (purely additive, non-breaking):

ExpressionAnalyzer trait and ExpressionAnalyzerRegistry in datafusion-physical-expr
SessionState::expression_analyzer_registry() getter
SessionStateBuilder::with_expression_analyzer_registry() setter
Three default trait methods on ExecutionPlan: uses_expression_level_statistics(), with_expression_analyzer_registry(), expression_analyzer_registry()
Config option datafusion.optimizer.use_expression_analyzer

No breaking changes. Default behavior is unchanged (config defaults to false).

Disclaimer: I used AI to assist in the code generation, I have manually reviewed the output and it matches my intention and understanding.

asolimando · 2026-04-01T17:23:04Z

@2010YOUY01: FYI I took a final pass on the PR and marked it as "reviewable"

kosiew

@asolimando

Thanks for the solid work here. The new analyzer direction looks promising, but I ran into a couple of issues that could affect correctness and usefulness of the stats. Left a few detailed comments below.

asolimando · 2026-04-02T17:38:10Z

@asolimando

Thanks for the solid work here. The new analyzer direction looks promising, but I ran into a couple of issues that could affect correctness and usefulness of the stats. Left a few detailed comments below.

Thanks to you @kosiew for the spot-on review, and for sharing your feedback. I have addressed the requested changes, happy to iterate further if needed!

kosiew

@asolimando

Thanks for the follow-up here. The issues called out in the earlier review look addressed, including the projection ordering fix, the equality and inequality selectivity registry lookup, and narrowing the injective arithmetic NDV rule. I did notice one remaining gap around registry propagation through planner and optimizer-created projections.

kosiew

@asolimando, I spotted an issue with NDV handling that can affect selectivity estimates depending on operand order.

…propagation (#21483) ## Which issue does this PR close? - Part of #21443 (Pluggable operator-level statistics propagation) - Part of #8227 (statistics improvements epic) ## Rationale for this change DataFusion's built-in statistics propagation has no extension point: downstream projects cannot inject external catalog stats, override built-in estimation, or plug in custom strategies without forking. This PR introduces `StatisticsRegistry`, a pluggable chain-of-responsibility for operator-level statistics following the same pattern as `RelationPlanner` for SQL parsing and `ExpressionAnalyzer` (#21120) for expression-level stats. See #21443 for full motivation and design context. ## What changes are included in this PR? 1. Framework (`operator_statistics/mod.rs`): `StatisticsProvider` trait, `StatisticsRegistry` (chain-of-responsibility), `ExtendedStatistics` (Statistics + type-erased extension map), `DefaultStatisticsProvider`. `PhysicalOptimizerContext` trait with `optimize_with_context` dispatch. `SessionState` integration. 2. Built-in providers for Filter, Projection, Passthrough (sort/repartition/etc), Aggregate, Join (hash/sort-merge/nested-loop/cross), Limit, and Union. NDV utilities: `num_distinct_vals`, `ndv_after_selectivity`. 3. `ClosureStatisticsProvider`: closure-based provider for test injection and cardinality feedback. 4. JoinSelection integration: `use_statistics_registry` config flag (default false), registry-aware `optimize_with_context`, SLT test demonstrating plan difference on skewed data. ## Are these changes tested? - 39 unit tests covering all providers, NDV utilities, chain priority, and edge cases (Inexact precision, Absent propagation, Partial aggregate delegation, GROUPING SETS delegation, join-type bounds, multi-key NDV, exact Cartesian product, CrossJoin, GlobalLimit skip+fetch) - 1 SLT test (`statistics_registry.slt`): three-table join on skewed data (8:1:1 customer_id distribution) where the built-in NDV formula estimates 33 rows (wrong; actual=66) and the registry conservatively estimates 100, producing the correct build-side swap ## Are there any user-facing changes? New public API (purely additive, non-breaking): - `StatisticsProvider` trait and `StatisticsRegistry` in `datafusion-physical-plan` - `ExtendedStatistics`, `StatisticsResult` types; built-in provider structs; `num_distinct_vals`, `ndv_after_selectivity` utilities - `PhysicalOptimizerContext` trait and `ConfigOnlyContext` in `datafusion-physical-optimizer` - `SessionState::statistics_registry()`, `SessionStateBuilder::with_statistics_registry()` - Config: `datafusion.optimizer.use_statistics_registry` (default false) Default behavior is unchanged. The registry is only consulted when the flag is explicitly enabled. Known limitations: - Column-level stats (NDV, min/max) at Join/Aggregate/Union/Limit boundaries are not improved: these operators call `partition_statistics(None)` internally, re-fetching raw child stats and discarding registry enrichment. 4 TODO comments mark the affected call sites; #20184 would close this gap. - No `ExpressionAnalyzer` integration yet (#21122). --- Disclaimer: I used AI to assist in the code generation, I have manually reviewed the output and it matches my intention and understanding.

…propagation (apache#21483) ## Which issue does this PR close? - Part of apache#21443 (Pluggable operator-level statistics propagation) - Part of apache#8227 (statistics improvements epic) ## Rationale for this change DataFusion's built-in statistics propagation has no extension point: downstream projects cannot inject external catalog stats, override built-in estimation, or plug in custom strategies without forking. This PR introduces `StatisticsRegistry`, a pluggable chain-of-responsibility for operator-level statistics following the same pattern as `RelationPlanner` for SQL parsing and `ExpressionAnalyzer` (apache#21120) for expression-level stats. See apache#21443 for full motivation and design context. ## What changes are included in this PR? 1. Framework (`operator_statistics/mod.rs`): `StatisticsProvider` trait, `StatisticsRegistry` (chain-of-responsibility), `ExtendedStatistics` (Statistics + type-erased extension map), `DefaultStatisticsProvider`. `PhysicalOptimizerContext` trait with `optimize_with_context` dispatch. `SessionState` integration. 2. Built-in providers for Filter, Projection, Passthrough (sort/repartition/etc), Aggregate, Join (hash/sort-merge/nested-loop/cross), Limit, and Union. NDV utilities: `num_distinct_vals`, `ndv_after_selectivity`. 3. `ClosureStatisticsProvider`: closure-based provider for test injection and cardinality feedback. 4. JoinSelection integration: `use_statistics_registry` config flag (default false), registry-aware `optimize_with_context`, SLT test demonstrating plan difference on skewed data. ## Are these changes tested? - 39 unit tests covering all providers, NDV utilities, chain priority, and edge cases (Inexact precision, Absent propagation, Partial aggregate delegation, GROUPING SETS delegation, join-type bounds, multi-key NDV, exact Cartesian product, CrossJoin, GlobalLimit skip+fetch) - 1 SLT test (`statistics_registry.slt`): three-table join on skewed data (8:1:1 customer_id distribution) where the built-in NDV formula estimates 33 rows (wrong; actual=66) and the registry conservatively estimates 100, producing the correct build-side swap ## Are there any user-facing changes? New public API (purely additive, non-breaking): - `StatisticsProvider` trait and `StatisticsRegistry` in `datafusion-physical-plan` - `ExtendedStatistics`, `StatisticsResult` types; built-in provider structs; `num_distinct_vals`, `ndv_after_selectivity` utilities - `PhysicalOptimizerContext` trait and `ConfigOnlyContext` in `datafusion-physical-optimizer` - `SessionState::statistics_registry()`, `SessionStateBuilder::with_statistics_registry()` - Config: `datafusion.optimizer.use_statistics_registry` (default false) Default behavior is unchanged. The registry is only consulted when the flag is explicitly enabled. Known limitations: - Column-level stats (NDV, min/max) at Join/Aggregate/Union/Limit boundaries are not improved: these operators call `partition_statistics(None)` internally, re-fetching raw child stats and discarding registry enrichment. 4 TODO comments mark the affected call sites; apache#20184 would close this gap. - No `ExpressionAnalyzer` integration yet (apache#21122). --- Disclaimer: I used AI to assist in the code generation, I have manually reviewed the output and it matches my intention and understanding.

asolimando · 2026-04-15T20:43:10Z

@kosiew the CI error seems unrelated, the same test suite passed for macos but not amd64, I can't reproduce and it doesn't seem it can be caused by changes in this PR, it feels like a flaky test but I'd like to get your opinion.

EDIT: confirmed it was a flaky test, fixed by #21657, force-pushing to resolve conflicts with main, no real changes w.r.t. the updated status I gave above, just a mechanical fix due to as_any removal

kosiew

@asolimando,

Thanks for the updates here, a lot of the earlier concerns have been addressed nicely. The projection ordering fixes and the tighter NDV handling look solid. I took another pass and things are generally in good shape, but there are still a couple of edge cases and behavioral inconsistencies worth tightening up before landing.

Introduce ExpressionAnalyzer, a chain-of-responsibility framework for expression-level statistics estimation (NDV, selectivity, min/max). Framework: - ExpressionAnalyzer trait with registry parameter for chain delegation - ExpressionAnalyzerRegistry to chain analyzers (first Computed wins) - DefaultExpressionAnalyzer: Selinger-style estimation for columns, literals, binary expressions, NOT, boolean predicates Integration: - ExpressionAnalyzerRegistry stored in SessionState, initialized once - ProjectionExprs stores optional registry (non-breaking, no signature changes to project_statistics) - ProjectionExec sets registry via Projector, injected by planner - FilterExec uses registry for selectivity when interval analysis cannot handle the predicate - Custom nodes get builtin analyzer as fallback when registry is absent

- Regenerate configs.md for new enable_expression_analyzer option - Add enable_expression_analyzer to information_schema.slt expected output - Fix unresolved doc links to SessionState and DefaultExpressionAnalyzer (cross-crate references use backticks instead of doc links) - Simplify config description

…putation - Fix expression_analyzer_registry doc comment misplaced between function_factory's doc comment and field declaration - Fix module doc example import path (physical_plan -> physical_expr) - Extract expression_analyzer_registry() helper in planner to avoid repeating the config check 4 times - Defer left_sel/right_sel computation to AND/OR arms only, avoiding unnecessary sub-expression selectivity estimation for comparison operators

…ptimizer loop Add trait methods on ExecutionPlan for expression-level statistics injection (uses_expression_level_statistics, with_expression_analyzer_registry, expression_analyzer_registry). The physical planner injects the registry after plan creation and re-injects after each optimizer rule that modifies the plan, gated by the use_expression_analyzer config flag.

…ty for OR predicates OR predicates are inherently outside interval arithmetic (a union of two disjoint intervals cannot be represented as a single interval). This test confirms that ExpressionAnalyzerRegistry computes the correct inclusion-exclusion selectivity (0.28 = 0.1 + 0.2 - 0.02) on a 1000-row input, versus the default 20% (200 rows) without a registry.

…ailable Return Delegate for all leaf predicates when NDV is unavailable, and propagate Delegate upward through AND/OR/NOT when any child has no estimate. DefaultExpressionAnalyzer now only produces a result when it has a genuine information advantage (NDV from column statistics).

… OR selectivity Add a reusable StatisticsTable (TableProvider + ExecutionPlan with user-supplied statistics) to the sqllogictest harness, and use it in expression_analyzer.slt

…s_any removal (apache#21573)

…e no-op rules gap

…ct column stats when no ExpressionAnalyzer

kosiew

This looks good to me.
Looking forward to approving this after merge conflict is resolved.

asolimando · 2026-04-20T13:31:01Z

This looks good to me. Looking forward to approving this after merge conflict is resolved.

Thanks @kosiew, I have resolved the conflicts and force-pushed again, mechanical fixes only.

…propagation (apache#21483) ## Which issue does this PR close? - Part of apache#21443 (Pluggable operator-level statistics propagation) - Part of apache#8227 (statistics improvements epic) ## Rationale for this change DataFusion's built-in statistics propagation has no extension point: downstream projects cannot inject external catalog stats, override built-in estimation, or plug in custom strategies without forking. This PR introduces `StatisticsRegistry`, a pluggable chain-of-responsibility for operator-level statistics following the same pattern as `RelationPlanner` for SQL parsing and `ExpressionAnalyzer` (apache#21120) for expression-level stats. See apache#21443 for full motivation and design context. ## What changes are included in this PR? 1. Framework (`operator_statistics/mod.rs`): `StatisticsProvider` trait, `StatisticsRegistry` (chain-of-responsibility), `ExtendedStatistics` (Statistics + type-erased extension map), `DefaultStatisticsProvider`. `PhysicalOptimizerContext` trait with `optimize_with_context` dispatch. `SessionState` integration. 2. Built-in providers for Filter, Projection, Passthrough (sort/repartition/etc), Aggregate, Join (hash/sort-merge/nested-loop/cross), Limit, and Union. NDV utilities: `num_distinct_vals`, `ndv_after_selectivity`. 3. `ClosureStatisticsProvider`: closure-based provider for test injection and cardinality feedback. 4. JoinSelection integration: `use_statistics_registry` config flag (default false), registry-aware `optimize_with_context`, SLT test demonstrating plan difference on skewed data. ## Are these changes tested? - 39 unit tests covering all providers, NDV utilities, chain priority, and edge cases (Inexact precision, Absent propagation, Partial aggregate delegation, GROUPING SETS delegation, join-type bounds, multi-key NDV, exact Cartesian product, CrossJoin, GlobalLimit skip+fetch) - 1 SLT test (`statistics_registry.slt`): three-table join on skewed data (8:1:1 customer_id distribution) where the built-in NDV formula estimates 33 rows (wrong; actual=66) and the registry conservatively estimates 100, producing the correct build-side swap ## Are there any user-facing changes? New public API (purely additive, non-breaking): - `StatisticsProvider` trait and `StatisticsRegistry` in `datafusion-physical-plan` - `ExtendedStatistics`, `StatisticsResult` types; built-in provider structs; `num_distinct_vals`, `ndv_after_selectivity` utilities - `PhysicalOptimizerContext` trait and `ConfigOnlyContext` in `datafusion-physical-optimizer` - `SessionState::statistics_registry()`, `SessionStateBuilder::with_statistics_registry()` - Config: `datafusion.optimizer.use_statistics_registry` (default false) Default behavior is unchanged. The registry is only consulted when the flag is explicitly enabled. Known limitations: - Column-level stats (NDV, min/max) at Join/Aggregate/Union/Limit boundaries are not improved: these operators call `partition_statistics(None)` internally, re-fetching raw child stats and discarding registry enrichment. 4 TODO comments mark the affected call sites; apache#20184 would close this gap. - No `ExpressionAnalyzer` integration yet (apache#21122). --- Disclaimer: I used AI to assist in the code generation, I have manually reviewed the output and it matches my intention and understanding.

xudong963

Thanks @asolimando!

The algorithmic contribution is genuinely useful, and thanks for your patience in keeping at it.

But the registry-injection plumbing adds three permanent ExecutionPlan trait methods and five struct fields to work around a missing parameter that #20184 is poised to add properly.

Before landing, I'd want alignment on whether to (a) wait for #20184 and land this on top of a StatisticsContext parameter, or (b) accept the injection design as a permanent API surface

asolimando · 2026-04-21T11:39:03Z

Thanks @asolimando!

The algorithmic contribution is genuinely useful, and thanks for your patience in keeping at it.

But the registry-injection plumbing adds three permanent ExecutionPlan trait methods and five struct fields to work around a missing parameter that #20184 is poised to add properly.

Before landing, I'd want alignment on whether to (a) wait for #20184 and land this on top of a StatisticsContext parameter, or (b) accept the injection design as a permanent API surface

Thanks @xudong963 for your thoughtful feedback, the injection design was meant as a stepping stone, not a permanent API surface, and I totally agree that adding the StatisticsContext parameter is the right long term solution, buying us freedom to provide an even richer context in the future. I wanted to mark the new trait methods as "experimental" but I couldn't find a proper mechanism for that in DataFusion.

Re. (b), I was under the impression that #20184 might land pretty soon, so I was basically counting on rebasing before finalizing, or shortly after, as breaking changes within the same unreleased version are generally tolerated, but if the timeline to merge #20184 is uncertain, (b) might not be ideal.

The cons of (a) is the risk of conflicts requiring to force-push, making it harder for reviewers to check incrementally.

In case it makes your decision easier, I can commit on helping with #20184's implementation, under both scenarios, if the current assignee is busy.

WDYT?

xudong963 · 2026-04-22T10:33:02Z

In case it makes your decision easier, I can commit on helping with #20184's implementation, under both scenarios, if the current assignee is busy.

Yes, please. If the current assignee is busy, taking that on is probably the fastest path to unblocking this PR in its final form. Happy to review on that side too. Also cc @jonathanc-n

I also want to hear some suggestions from @alamb about the next step!

asolimando · 2026-04-23T21:06:36Z

In case it makes your decision easier, I can commit on helping with #20184's implementation, under both scenarios, if the current assignee is busy.

Yes, please. If the current assignee is busy, taking that on is probably the fastest path to unblocking this PR in its final form. Happy to review on that side too. Also cc @jonathanc-n

I also want to hear some suggestions from @alamb about the next step!

Hey @xudong963, I have opened #21815 to close #20184 as requested (I will ping you there too)

github-actions Bot added physical-expr Changes to the physical-expr crates core Core DataFusion crate common Related to common crate physical-plan Changes to the physical-plan crate documentation Improvements or additions to documentation sqllogictest SQL Logic Tests (.slt) labels Mar 23, 2026

asolimando force-pushed the asolimando/ndv-expression-analyzer branch from 322b97f to f101c51 Compare March 25, 2026 12:05

2010YOUY01 mentioned this pull request Mar 26, 2026

Pluggable expression-level statistics estimation (ExpressionAnalyzer) #21120

Open

9 tasks

asolimando force-pushed the asolimando/ndv-expression-analyzer branch 2 times, most recently from dfa1324 to f6f27ac Compare April 1, 2026 17:18

asolimando marked this pull request as ready for review April 1, 2026 17:18

kosiew requested changes Apr 2, 2026

View reviewed changes

Comment thread datafusion/physical-expr/src/projection.rs

Comment thread datafusion/physical-expr/src/expression_analyzer/default.rs Outdated

Comment thread datafusion/physical-expr/src/expression_analyzer/default.rs Outdated

asolimando requested a review from kosiew April 2, 2026 17:38

kosiew requested changes Apr 4, 2026

View reviewed changes

Comment thread datafusion/core/src/physical_planner.rs Outdated

2010YOUY01 mentioned this pull request Apr 5, 2026

Estimate aggregate output rows using existing NDV statistics #20926

Merged

kosiew requested changes Apr 8, 2026

View reviewed changes

Comment thread datafusion/physical-expr/src/expression_analyzer/default.rs Outdated

asolimando force-pushed the asolimando/ndv-expression-analyzer branch from 54a0df7 to ae2a0b8 Compare April 15, 2026 17:43

github-actions Bot added the optimizer Optimizer rules label Apr 15, 2026

asolimando force-pushed the asolimando/ndv-expression-analyzer branch 2 times, most recently from c37838b to 42d0f8e Compare April 15, 2026 19:41

asolimando requested a review from kosiew April 15, 2026 20:15

asolimando force-pushed the asolimando/ndv-expression-analyzer branch from b6d2621 to 189287f Compare April 16, 2026 09:50

kosiew requested changes Apr 16, 2026

View reviewed changes

Comment thread datafusion/core/src/physical_planner.rs

Comment thread datafusion/physical-plan/src/operator_statistics/mod.rs Outdated

asolimando requested a review from kosiew April 16, 2026 12:16

asolimando added 15 commits April 20, 2026 10:00

Snapshot column stats for analyzer to avoid ordering dependency

50badbc

Use registry NDV for equality/inequality selectivity on expressions

64e80c9

Narrow injective arithmetic to addition and subtraction only

a2620ee

Make resolve_ndv symmetric: use max NDV across both operands

090ac7d

Clarify enable_expression_analyzer scope in config and doc comments

70b1ba2

test(expression_analyzer): add StatisticsTable and end-to-end SLT for…

922d578

… OR selectivity Add a reusable StatisticsTable (TableProvider + ExecutionPlan with user-supplied statistics) to the sqllogictest harness, and use it in expression_analyzer.slt

fix: replace as_any().downcast_ref with downcast_ref after upstream a…

9b6d506

…s_any removal (apache#21573)

fix: inject ExpressionAnalyzer registry before optimizer loop to clos…

0831066

…e no-op rules gap

fix: align JoinStatisticsProvider with config gate, fall back to dire…

3d6d74b

…ct column stats when no ExpressionAnalyzer

kosiew reviewed Apr 20, 2026

View reviewed changes

fix: remove stale comment about NDV pinning in statistics_helper

f2708a7

asolimando force-pushed the asolimando/ndv-expression-analyzer branch from b79d090 to f2708a7 Compare April 20, 2026 13:29

kosiew approved these changes Apr 20, 2026

View reviewed changes

xudong963 reviewed Apr 21, 2026

View reviewed changes

xudong963 requested review from adriangb and alamb April 21, 2026 06:59

asolimando mentioned this pull request Apr 23, 2026

Add StatisticsContext parameter to partition_statistics #21815

Open

3 tasks

Conversation

asolimando commented Mar 23, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Which issue does this PR close?

Rationale for this change

What changes are included in this PR?

Are these changes tested?

Are there any user-facing changes?

Uh oh!

asolimando commented Apr 1, 2026

Uh oh!

kosiew left a comment • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

asolimando commented Apr 2, 2026

Uh oh!

kosiew left a comment • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

kosiew left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

asolimando commented Apr 15, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

kosiew left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

kosiew left a comment

Choose a reason for hiding this comment

Uh oh!

asolimando commented Apr 20, 2026

Uh oh!

xudong963 left a comment

Choose a reason for hiding this comment

Uh oh!

asolimando commented Apr 21, 2026

Uh oh!

xudong963 commented Apr 22, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

asolimando commented Apr 23, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

4 participants

asolimando commented Mar 23, 2026 •

edited

Loading

kosiew left a comment •

edited

Loading

kosiew left a comment •

edited

Loading

asolimando commented Apr 15, 2026 •

edited

Loading

xudong963 commented Apr 22, 2026 •

edited

Loading